Rules engines have been used to affect objects. In order to permit the application of rules to events occurring within objects, a rule engine must be capable of capturing events from the objects and programming against them. An overall architecture of a rule engine that hosts an application according to the prior art is depicted in FIG. 1. Application objects 10, 11 and 12 call rule engine 20 upon the occurrence of predefined events. Rule engine 20 evaluates rule conditions, such as rule condition 50, to optimize when the rule should even be considered for execution by building RETE NET 30 using rule options expressed by the user. Rule 70 is accessed, as is rule condition 50. The rule is then executed as shown in box 60.
In order to function properly, rule engine 20 imposes certain requirements upon application objects 10, 11 and 12. First of all, rule engine 20 must be able to receive the events from application objects 10, 11 and 12 that are to be used with rule 70. Events that may be desirable to receive include field/property modification events, method calling events, object creation events and object deletion events.
In order for a programmer to be able to code rules and conditions, such as rule 70 and condition 50, that can be used against application objects 10, 11 and 12, the exact types of objects being used must be known to the programmer as well as details on the properties that are being used in the rules and conditions. The programmer must employ syntax that is able to express a wide variety of logistics while programming the rules and conditions.
Traditionally application programmers had two methods with which to accomplish this. The first is to have the rule engine define an API for the events that it requires. Under this scenario, the application objects would fire such events explicitly when they occur.
The second method would be to have the rule engine define an object model that internally fires events automatically. Programmers of such objects would then have to ensure that each application object would adhere to the object model.
In either of these prior art solutions, programmers of objects would have to explicitly program hooks into the objects that would reach out of the object and engage the rule engine when a specific event occurred through either programming the objects to a predefined object model or to meet the API's requirements. Thus, programmers had to be aware of what the rule engines were looking for, spend time coding in the appropriate hooks and adhere to the syntax supported by the object model or API. If an unforeseen rule were to be developed for use, the programming of the objects may have to be revisited in order to update the existing hooks or add new hooks to account for the new rule. Thus, these prior art frameworks are inefficient and may cause delays in deployment of needed services due to more time-intensive programming and the possibility of needed reprogramming.
The number of Java based applications have grown considerably along with the growth of the Internet. In certain systems, events occurring within Java objects may cause a desire to take some action. One such system is a business-to-business electronic marketplace. For instance, in an electronic marketplace a shopping basket may be a Java object. When a method is executed that adds an item to that shopping basket, it may be desirable to cause some action to occur through the use of a rules engine, such as offering additional items to the shopper for possible addition to the shopping basket that relate to the newly added item.
Thus a need exists for a framework that would permit the application of Java rules through a rule engine without the need for the explicit insertions of hooks within Java objects.